1. Technical Field
The invention relates to implementation and execution of constraints in a database based on an entity-relationship data model used to represent business data. Still more particularly, the invention relates to determination of applicable constraints upon user request for the modification, creation, or destruction of entity instances and to the automatic generation and execution of code for the applicable constraints.
2. Description of the Related Art
Entity-relationship (ER) modelling is a diagrammatic technique used to structure information about situations, for example, social organizations or business enterprises. ER modeling provides a framework to express information as data and to place the data in data structures for use as a database. ER data models are specifically designed to support an intuitive representation of a world through graphic presentation of entity types and relationships between entities types. The entity-relationship data model was proposed by Peter Pin-Shan Chen in his article The Entity-Relationship Model--Toward a Unified View of Data which appeared in the ACM Transactions on Database Systems, Vol. 1, No. 1, pages 9-37 (1976).
The AD/Cycle Information Model, described in the reference manual AD/Cycle Information Model: Reference Volume 1: Enterprise Submodel, which is available from International Business Machines Corporation, provides one vehicle for ER modeling. In the model, entity types are described for a plurality of conceptual constructs. The entity type, ENT.sub.-- ENTITY.sub.-- TYPE, is used as a template to categorize a class of people, things, or concepts having characteristics of interest to an enterprise database administrator.
An entity within a class of people, a class of things, or within a class of concepts, becomes an entity instance by classification into a specified ENT.sub.-- ENTITY.sub.-- TYPE. Everything that is given a description, that is anything which is the subject of a fact comprehended by the system, is an entity instance. Each entity type is a set of entity instances that are described by the same kinds of facts. Facts about an entity translate into attribute types, relationship links, or compound facts about entity instances, which identify the entity instance.
Relationship links are the directional component in the definition of a relationship type between instances of one or more entity types. An instance of a relationship type represents a type of symmetric connection or association between two entity instances of given types. An example of a symmetric or reciprocal relationship between two entities is given by the statement "John and Sally are siblings". Relationship links are directional, and two entity instances may be linked by complementary relationship links. An example of complementary relationship links would be "John is a child of Sally" and "Sally is a parent of John". Either type of relationship, as entities, have attributes, which are characterized for specific relationship instances by assignment of values. Although relationship links and relationship types are a kind of entity type, they are not referred to as such in this paper unless otherwise stated.
Completeness of a model is not a goal. A data model for a business enterprise may include the entity type "employees" meaning people employed by the enterprise. It would rarely be of interest to further include an entity type "people" and relate instances of that group into the entity type "employees" through a relationship "person-employee", even though such a representation might be feasible. It is simply impossible to record every conceivable piece of information. Entity types and relationship types are the collections of particular entity instances or relationship instances of the particular types defined.
Attributes have values for given entity and relationship instances. For example, an employee has an employee number, a name, a start date, an age, et cetera. An attribute is a map between instances of an entity type and a value set. An entity instance may be identified by an attribute value where the attribute mapping from the entity instance set to the value set is one-to-one. These are entity keys. Where more than one attribute meets this criteria, one is selected as the primary key. Primary keys may also be defined for a relationship link. Since a relationship instance is identified by the involved entities, the primary key of the instance may be formed by the primary keys of the involved entity instances. Keys may be provided by an arbitrary or abstract value given an entity instance, such as an employee number for an employee of a business.
Information associated with entities is separated from information associated with relationships. There is of course no bright line separating that which is an entity from that which is a relationship. Categorization of an object in a particular application is a problem for the designer of a specific database.
An ER diagram is representable in a visual format, as a chart. This is an advantage in terms of understandability, but has a disadvantage in that some important, information cannot be graphically represented. This information is accounted for by providing constraints, or logical limitations, for the model. A constraint is used to disallow an otherwise valid update of a database. Constraints are very precise, pseudo-logic rules about how items in a data model may be used.
In the AD/Cycle Information Model, some constraints have been hard coded for entity types, relationship links and relationship types. These are stored in executable form and thereby prevent a database designer from violating a constraint. Many other constraints have not been automated and their implementation has required manual checking upon creation, deletion and modification of entity instances.